Electronic commerce using a transaction network

ABSTRACT

The present invention is directed to a transaction network that facilitates and simplifies purchase transactions between any number of customers and any number of merchants. The transaction network is primarily utilized in the sale and purchase of digital content via a network such as the Internet. The transaction network registers and authenticates customer purchase activities and maintains customer account data including payment information. Once registered, a customer will generally not register again for further purchase activities at participating merchant sites. Additionally, the transaction network provides a single, central authentication mechanism for all participating merchant sites using a single customer identifier and password. Further, the transaction network accumulates purchase information across all of the merchant sites and the ultimate payment processing of those purchase transactions. Payment processing generally occurs on a periodic basis, enabling the accumulation of multiple purchase transactions within a participating customer&#39;s account. The network additionally preferably provides customers with centralized, automated services for customer account management, product refunds, subscription management, and multiple purchasing accounts linked to the same payment account.

TECHNICAL FIELD

[0001] The present invention is directed to the field of electroniccommerce and more particularly, to the field of facilitating userregistration and authentication, purchasing from multiple merchants,aggregating payment transactions, and merchant remittance for electroniccommerce transactions, such as those conducted on the Internet.

BACKGROUND OF THE INVENTION

[0002] The World Wide Web (“the Web”) is an interactive computerenvironment. The Web uses a collection of common protocols, includingthe Hypertext Transfer Protocol (“HTTP”), and file formats, includingHypertext Markup Language (“HTML”), to enable users to obtaininformation from or exchange information with a huge number oforganizations, via the Internet, from virtually anywhere in the world.In order to establish a presence on the Web, organizations generallyconstruct a “Web site.” Such a Web site generally includes a collectionof documents relating to the organization that is accessible by usersusing an address on the Web, called a Universal Resource Locator(“URL”), publicized by the organization.

[0003] The Web is increasingly used as a channel for commercialactivity. Many organizations have achieved great success at sellingproducts and services through their Web sites. For instance, asignificant fraction of the airline tickets, music compact discs, andbooks sold today are sold via the Web.

[0004] In order to attract customers for such sales, a merchant mustgenerally advertise its Web site on the Web or another more traditionalmedia, or otherwise pay to attract customers. In most such sales, thepurchase price is paid using a credit card or check card. In order tocomplete such a purchase, the customer provides to the merchantinformation associated with the credit card or check card, such as thenumber and expiration date of the credit card or check card. Thecustomer commonly also provides additional information about himself orherself, such as name and postal address for delivering physical goods.

[0005] The merchant uses the provided credit card or debit cardinformation to generate a request for payment of the purchase price,which it transmits to a payment processor. The payment processor in turncharges the purchase price to the customer's credit card or check card,and credits the merchant's account in the amount of the purchase price.For a particular customer, this process is generally repeated for eachmerchant from which the customer makes a purchase. Similarly, a merchantgenerally repeats this process for each purchase made by a customer.

[0006] The foregoing approach is efficient for purchases having asignificant purchase price, such as those above US$ 20. However, becausea significant portion of the actual costs of processing a credit card orcheck card transaction are fixed and not related to the amount of thetransaction, processing credit card transactions for lower amounts isgenerally cost-prohibitive. As a result, credit card and check cardtransactions are generally not used to purchase goods and serviceshaving a relatively low price, such as those below US$ 20. Additionally,the high cost of providing customer service on the Internet, includingsuch recurring operations as supplying lost passwords, raises the costfor selling goods, thus raising the minimum price at which goods must besold to realize a profit.

[0007] While other forms of payment, such as cash proxies, have beenproposed for use in such lower-priced transactions, these other forms ofpayment have failed to achieve acceptance on the Web. This is largelydue to the amount of extra interaction that these cash proxy paymentmethods require from the customer, as customers are often unwilling totolerate a great deal of inconvenience to purchase an inexpensive item.Moreover, even if such an alternative form of payment did achieveacceptance on the Web, they typically impose significant processingcosts on those merchants that accept them, and do nothing to alleviatecustomer service costs.

[0008] Since credit card and check card transactions are the only formsof payment that have achieved general acceptance on the Web, it isgenerally not possible to buy such lower-priced goods and services onthe Web. These lower-priced purchases are, however, important. Inparticular, digital goods, such as electronic magazine articles, music,or games, delivered via the Web have a very small marginal cost. Whilethere may be a significant demand for some digital goods if priced atappropriately modest levels, when their price is set at or above theminimum viability threshold for credit card and check card transactions,demand is very low or nonexistent. Therefore, because goods cannot besold via credit card or check card at a price below the minimumviability threshold, and there is little demand at or above the minimumviability threshold, such goods are incapable of generating significantrevenue and generally are not offered for sale.

[0009] The transactional model discussed above, in which customers makepurchases directly from merchants using credit card or check cardtransactions, have serious disadvantages for both customers andmerchants. First, as noted above, low-priced purchases are generallyimpossible to conduct using this model, which generally precludescustomers from purchasing and merchants from selling certain products,and limits the number of customers that can purchase others. Further,the model requires each customer to expend significant effort managinghis or her relationship with each merchant, and also requires eachmerchant to make significant up-front and continuing investments inmanaging its relationship with its customers and with its paymentprocessor.

[0010]FIG. 1 is a relationship diagram showing the relationships arisingbetween customers, merchants, and payment processors in accordance withthe conventional transaction model. The diagram shows a number ofcustomers 110, who engage in purchase transactions with a number ofmerchants 120. Each line between a customer 110 and a merchant 120represents a relationship between the customer and the merchant thatmust be managed by both the customer and the merchant.

[0011] From the customer's perspective, he or she must provide creditcard or check card payment information to each new merchant from whichthe customer makes a purchase. To do so is generally both inconvenient,because the customer must enter the same information over and over, anddisconcerting, because the customer is required to entrust thissensitive information to several different parties, one or more of whichmay be untrustworthy. In addition, customers must learn the customerservice policies of every merchant from which they purchase, which canbe a burdensome process, especially for modestly-priced purchases.

[0012] From the merchant's perspective, it must build, operate, andscale up an infrastructure for accepting credit or check card paymentsfrom customers, for delivering purchased goods, and for providingcustomer service to those customers. Such infrastructures are generallyexpensive, and often distract merchants from their more fundamental roleof creating and selling products.

[0013] Further disadvantages arise in the conventional model when amerchant subjects customers to user authentication. Merchants often useuser authentication, the process of establishing that a Web user isactually a returning customer, to enable customers to make subsequentpurchases using the payment information from a previous purchase, or tofacilitate continuing consumption of purchased goods, such as continuedaccess to an online periodical to which the customer has purchased asubscription. Generally, in order to authenticate as a returningcustomer, a user must enter a user name and password that is specific toeach merchant. From the customer's perspective, submitting to userauthentication involves the disadvantages of having to use a user namethat is unique among those of each merchant's customers and thus is notalways freely chosen by the customer, having to remember or record eachof these different member names, and having to re-authenticate each timethe customers move from the Web site of one merchant to the Web site ofanother, which can prove burdensome and frustrating for users.

[0014] From the merchant's perspective, performing user authenticationinvolves the disadvantages of having to build, operate, and scale up amechanism for performing user authentication and a customer database tosupport user authentication, an effort that is potentially both costlyand distracting. In addition to relationships with its customers, in theconventional model a merchant must also maintain a relationship with apayment processor 130 to process credit or check card transactions.Maintaining a relationship with a payment processor requires themerchant to shop for and negotiate a contract with a payment processor,and to build, operate, and scale up a mechanism for communicating withthe payment processor, another effort that is potentially both costlyand distracting.

[0015] It can be seen from the foregoing that, from the perspective ofmerchants, a reliable system for selling goods, including lower-pricedgoods on the Web, without having to develop an infrastructure foraccepting payment, for registering and authenticating customers wouldhave significant utility, or for providing customer support. It canfurther be seen that, from the perspective of customers, a convenientsystem that facilitates the purchase of goods, including lower-pricedgoods from a number of different merchants without having to submitpayment information to each merchant or reauthenticate to each merchant,and which provides centralized customer service for purchases made frommultiple merchants would also have significant utility.

SUMMARY OF THE INVENTION

[0016] The present invention provides a new type of transaction network(“the network”) for facilitating purchase transactions between anynumber of customers and any number of merchants participating in thenetwork. The network is well-suited to the purchase of low-priced“digital goods.” as well as the purchase of other products and services,especially those having relatively low prices, and enables customer touse traditional forms of payment, such as credit cards. The networkrelieves merchants of the burdens of each maintaining a separateinfrastructure for authenticating and accepting payment from customers,delivering goods, and providing customer service. The network furtherprovides a single registration process during which the customerprovides credit card payment information once for all of the merchants,as well as universal authentication to the Web sites of all of themerchants through a single user interaction. The network yet furtherfacilitates the migration of large existing groups of users from otherauthentication systems, such as those of merchants, to theauthentication system provided by the network. The network additionallypreferably provides customers with centralized, automated services forcustomer account management, product refunds, subscription management,and multiple purchasing accounts linked to the same payment account.

[0017]FIG. 2 is a relationship diagram showing the relationships definedfor customers and merchants by the network. It can be seen that eachcustomer 210, rather than maintaining a separate purchasing relationshipwith each merchant 220, need only maintain a single purchasingrelationship with the network 240. This means that the customer needonly provide payment information and to register and authenticate to thenetwork, not to each merchant. Similarly, each merchant 220, rather thanmaintaining a relationship with each customer 210, need only maintain asingle relationship to the network. This means that, rather thanproviding infrastructure for accepting payment from customers,delivering goods to customers, registering and authenticating customers,and providing customer service, the merchants may rely uponcorresponding functionalities of the network. Further, rather thanthemselves maintaining a relationship with a charge processor 230, themerchants 220 can rely on the relationship with the charge processormaintained by the network 240. Participation in the network thus freesboth customers and merchants of the substantial burdens of theconventional transaction model described above.

[0018] In accordance with the present invention, a new customer mayvisit the Web site of any merchant. When the user selects, on themerchant's Web site, a product or service (hereafter “item”) forpurchase, the network determines whether the customer is presentlyregistered and authenticated with the network. If the customer is notpresently registered, the network enables the customer to register withthe network by providing identity and payment information. The identityinformation provided by the customer preferably includes a memberidentifier and a password for use with the network, as well as anelectronic mail (“email”) address. The payment information preferablyincludes a credit card number, or other information usable to charge thecustomer for purchases. As part of registration process, the networkpreferably verifies the provided payment information. At the conclusionof registration process, the registered customer is permitted topurchase the item. As a result of the purchase, the purchased item isprovided to the customer, and a transaction record is created thatidentifies the customer, the merchant, and the amount of the purchase.The visual user interfaces for these registration and purchase processesare preferably cobranded with the trademarks of the merchant and theoperator of the network, to indicate that both parties are collaboratingin providing the purchasing experience enjoyed by the customer.

[0019] After the customer has registered, the customer is effectivelysigned on to the network for a period of time, such as several hours.After registering, the customer may again sign on to the network byidentifying, “or authenticating,” himself or herself to the network byentering the member identifier and password. During the time that thecustomer is signed on, the customer may browse and purchase items fromany Web site in the network without repeating the authenticationprocess.

[0020] The network periodically reviews the unbilled purchasetransaction records of each customer resulting from purchases made bythe customer at any site. When the amounts of these records exceed athreshold value, preferably determined based upon the amount at whichthe transaction costs for the form of payment provided by the customerbecome reasonable, the network generates a payment request requestingpayment of the total amount. The network then combines the paymentrequests generated for a number of users and transmits them to a paymentprocessor for payment. The payment processor returns a settlementindication for each payment request indicating that the payment requesthas been settled or declined.

[0021] At this point, the merchants from whom the customer purchased theitems are each credited with a portion of the corresponding purchaseprice, and the purchase transaction records represented by the paymentrequest are marked as paid. In this manner, the network efficientlyfacilitates purchase transactions having relatively low purchase amountsusing traditional forms of payment. The network further facilitatespurchases having relatively low prices by providing centralized servicesfor seeking refunds and managing subscriptions, and by providingmultiple purchasing accounts linked to a single payment account. Byproviding these customer service functionalities to merchants, thenetwork substantially lowers merchants' transaction processing costs,thereby enabling merchants to offer for sale modestly-priced goods.

[0022] In a further embodiment, during registration, the network permitsthe customer to provide a member identifier that is not unique among allof the customers of the network. In this embodiment, the network storesa unique identifier for the customer, along with the member identifierspecified by the customer, in a cookie on the customer's computersystem. When the customer subsequently authenticates by providing themember identifier, the network uses the member identifier to find theunique identifier on the customer's computer system, and uses the memberidentifier together with the unique identifier to authenticate thecustomer. In this way, the network allows customers to use non-uniquemember identifiers. This improves the customer experience for allcustomers, as it enables them to choose a particular member identifierwithout regard for its use by other customers. This is especiallyvaluable where the network has a large number of customers. Facilitatingnon-unique member identifiers also permits the operator of the networkto “absorb” or “import” existing groups of customers from other onlineservices, where they already have member identifiers to which they areaccustomed, and which may be redundant with the member identifiers ofother customers of the network.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023]FIG. 1 is a relationship diagram showing the relationships arisingbetween customers, merchants, and payment processors in accordance withthe conventional transaction model.

[0024]FIG. 2 is a relationship diagram showing the relationships definedfor customers and merchants by the network.

[0025]FIG. 3 is a high-level block diagram of the computer networkenvironment in which the transaction network preferably operates.

[0026]FIG. 4 is a high-level block diagram of a typical merchantcomputer system.

[0027]FIG. 5 is a high-level block diagram of a typical customercomputer system.

[0028]FIG. 6 is a high-level block diagram of a typical network servicecenter computer system.

[0029]FIG. 7 is a screen shot diagram showing a Web page displayed by amerchant.

[0030]FIG. 8 is a flow diagram showing the steps preferably performed bythe network as part of the purchasing process.

[0031]FIG. 9 is a flow diagram showing the steps preferably performed bythe network in order to authenticate a customer.

[0032]FIG. 10 is a screenshot diagram showing the sign on dialogpreferably displayed by the network to collect the member identifier andpassword.

[0033]FIG. 11 is a flow diagram showing the steps preferably performedby the network in order to register the customer with the network.

[0034]FIG. 12 is a screenshot diagram showing a registration dialog1200, into which the user enters personal and payment information.

[0035]FIG. 13 is a screenshot diagram showing a confirmation dialogpreferably displayed by the network in step 808.

[0036]FIG. 14 is a screenshot diagram showing provision of a purchaseditem.

[0037]FIG. 15 is a screenshot diagram showing a Web page of a secondmerchant.

[0038]FIG. 16 is a screenshot diagram showing the confirmation dialogdisplayed in response to the customer's selection of link 1524.

[0039]FIG. 17 is a screenshot diagram showing the provision of theadditional purchased item.

[0040]FIG. 18 is a table diagram showing the transaction databasemaintained by the network.

[0041]FIG. 19 is a flow diagram of the steps preferably performed by thenetwork in order to aggregate the transaction records in the transactiondatabase into authorizations sent to a payment processor.

[0042]FIG. 20 is a flow diagram showing the steps preferably performedby the network in order to process a settlement report.

[0043]FIG. 21 is a screenshot diagram showing a sample customerstatement.

[0044]FIG. 22 is a screenshot diagram showing a sample item informationpage.

[0045]FIG. 23 is a screenshot diagram showing a sample refund request.

[0046]FIG. 24 is a screenshot diagram showing a sample confirmationscreen confirming a refund request.

[0047]FIG. 25 is a screenshot diagram showing a sample statementreflecting the submission of a refund request.

[0048]FIG. 26 is a screenshot diagram showing a sample subscriptionmanagement page.

[0049]FIG. 27 is a screenshot diagram showing a sample subscriptioninformation page.

[0050]FIG. 28 is a screenshot diagram showing a sample registration pagefor registering an additional purchasing account for an existing paymentaccount.

[0051]FIG. 29 is a screenshot diagram showing a sample customerstatement showing purchases made with the additional purchasing account.

[0052]FIG. 30 is a screenshot diagram showing a sample customerstatement showing purchases made with multiple purchasing accounts thatare each associated with the same payment account.

DETAILED DESCRIPTION OF THE INVENTION

[0053] The present invention provides a new type of transaction network(“the network”) for facilitating purchase transactions between anynumber of customers and any number of merchants participating in thenetwork. The network is well-suited to the purchase of low-priced“digital goods,” as well as the purchase of other products and services,especially those having relatively low prices, and enables customer touse traditional forms of payment, such as credit cards. The networkrelieves merchants of the burdens of each maintaining a separateinfrastructure for authenticating and accepting payment from customers,delivering goods, and providing customer service. The network furtherprovides a single registration process during which the customerprovides credit card payment information once for all of the merchants,as well as universal authentication to the Web sites of all of themerchants through a single user interaction. The network yet furtherfacilitates the migration of large existing groups of users from otherauthentication systems, such as those of merchants, to theauthentication system provided by the network. The network additionallypreferably provides customers with centralized, automated services forcustomer account management, product refunds, subscription management,and multiple purchasing accounts linked to the same payment account.

[0054]FIG. 2 is a relationship diagram showing the relationships definedfor customers and merchants by the network. It can be seen that eachcustomer 210, rather than maintaining a separate purchasing relationshipwith each merchant 220, need only maintain a single purchasingrelationship with the network 240. This means that the customer needonly provide payment information to register and authenticate thenetwork, not to each merchant. Similarly, each merchant 220, rather thanmaintaining a relationship with each customer 210, need only maintain asingle relationship to the network. This means that, rather thanproviding infrastructure for accepting payment from customers,delivering goods to customers, registering and authenticating customers,and providing customer service, the merchants may relay uponcorresponding functionalities of the network. Further, rather thanthemselves maintaining a relationship with a charge processor 230, themerchants 220 can rely on the relationship with the charge processormaintained by the network 240. Participation in the network thus freesboth customers and merchants of the substantial burdens of theconventional transaction model described above.

[0055] In accordance with the present invention, a new customer mayvisit the Web site of any merchant. When the user selects, on themerchant's Web site, a product or service (hereafter “item”) forpurchase, the network determines whether the customer is presentlyregistered and authenticated with the network. If the customer is notpresently registered, the network enables the customer to register withthe network by providing identity and payment information. The identityinformation provided by the customer preferably includes a memberidentifier and a password for use with the network, as well as anelectronic mail (“email”) address. The payment information preferablyincludes a credit card number, or other information usable to charge thecustomer for purchases. As part of registration process, the networkpreferably verifies the provided payment information. At the conclusionof registration process, the registered customer is permitted topurchase the item. As a result of the purchase, the purchased item isprovided to the customer, and a transaction record is created thatidentifies the customer, the merchant, and the amount of the purchase.The visual user interfaces for these registration and purchase processesare preferably cobranded with the trademarks of the merchant and theoperator of the network, to indicate that both parties are collaboratingin providing the purchasing experience enjoyed by the user.

[0056] After the customer has registered, the customer is effectivelysigned on to the network for a period of time, such as several hours.After registering, the customer may again sign on to the network byidentifying, “or authenticating,” himself or herself to the network byentering the member identifier and password. During this time that thecustomer is signed on, the customer may browse and purchase items fromany Web site in the network without repeating the authenticationprocess.

[0057] The network periodically reviews the unbilled purchasetransaction records of each customer resulting from purchases made bythe customer at any site. When the amounts of these records exceed athreshold value, preferably determined based upon the amount at whichthe transaction costs for the form of payment provided by the customerbecome reasonable, the network generates a payment request requestingpayment of the total amount. The network then combines the paymentrequests generated for a number of users and transmits them to a paymentprocessor for payment. The payment processor returns a settlementindication for each payment request indicating that the payment requesthas been settled or declined.

[0058] At this point, the merchants from whom the customer purchased theitems are each credited with a portion of the corresponding purchaseprice, and the purchase transaction records represented by the paymentrequest are marked as paid. In this manner, the network efficientlyfacilitates purchase transactions having relatively low purchase amountsusing traditional forms of payment. The network further facilitatespurchases having relatively low prices by providing centralized servicesfor seeking refunds and managing subscriptions, and by providingmultiple purchasing accounts linked to a single payment account. Byproviding these customer service functionalities to merchants, thenetwork lowers their transaction processing cost substantially, therebyenabling merchants to offer for sale modestly-priced goods.

[0059] In a further embodiment, during registration, the network permitsthe customer to provide a member identifier that is not unique among allof the customers of the network. In this embodiment, the network storesa unique identifier for the customer, along with the member identifierspecified by the customer, in a cookie on the customer's computersystem. When the customer subsequently authenticates by providing themember identifier, the network uses the member identifier to find theunique identifier on the customer's computer system, and uses the memberidentifier together with the unique identifier to authenticate thecustomer. In this way, the network allows customers to use non-uniquemember identifiers. This improves the customer experience for allcustomers, as it enables them to choose a particular member identifierwithout regard for its use by other customers. This is especiallyvaluable where the network has a large number of customers. Facilitatingnon-unique member identifiers also permits the operator of the networkto “absorb” or “import” existing groups of customers from other onlineservices, where they already have member identifiers to which they areaccustomed, and which may be redundant with the member identifiers ofother customers of the network.

[0060]FIG. 3 is a high-level block diagram of the computer networkenvironment in which the transaction network preferably operates.Merchant computer systems 310 are computer systems operated by or onbehalf of merchants that make items available for purchase by customersof the network. Merchant computer systems 310 preferably each provide aWeb server that serves Web pages, some of which offer items for sale.The merchant computer systems 310 are connected to customer computersystems 330 via a network 320, such as the Internet. The customercomputer systems 330 are usable by customers to browse the Web pagesserved by the merchant computer systems 310. When doing such browsing, acustomer may use a customer computer system 330 to purchase an itemoffered for sale. Such purchase is communicated over the network 320 toa network service center computer system, which makes a record of thetransaction. The network service center computer system 340 periodicallycollects together transactions entered into by each user, aggregatesthem into requests for payment, and forwards these payment requests overa secure network 350 to a payment processor computer system 360 forpayment. The configurations of several of the computer systems shown inFIG. 3 are discussed below in conjunction with FIGS. 4-6. While thenetwork is preferably implemented on computer systems configured in thismanner, those skilled in the art will recognize that the network may beadvantageously implemented on combinations of computer systems otherthan those shown in these figures.

[0061]FIG. 4 is a high-level block diagram of a typical merchantcomputer system. The merchant computer system 310 includes one or morecentral processing units (“CPUs”) 410, and a network connection 420 forconnecting to the network 320. The merchant computer system furthercomprises computer storage 430, which may include both transient storagedevices, such as random access memory, and persistent storage devices,such as hard drives. The storage preferably includes an HTTP serverprogram 431 for serving Web pages 432 offering items for sale. Thestorage preferably also includes: a product database 433 for storingitems offered for sale; a transaction engine 434 provided by theoperator of the network to conduct the sale and delivery of items toauthenticated customers and an authorization subsystem program 435,provided by the operator of the network to manage authorization ofcustomers to the merchant Web site. The merchant computer system furtherincludes a computer-readable media drive 440, which can be used toinstall software products, including the network, which are provided ona removable computer-readable medium, such as a CD-ROM or a DVD.

[0062]FIG. 5 is a high-level block diagram of a typical customercomputer system. The customer computer system 330 has one or more CPUs510 and a network connection 520. The customer computer system furtherhas a visual display 530, such as a video monitor for displaying Webpages, a keyboard 540 for inputting text, and a pointing device 550,such as a mouse, for selecting positions on the display. The customercomputer system further includes transient and/or persistent storage 560containing a Web browser program 561 for displaying and interacting withWeb pages, and a cookie file 562 containing information stored on thecustomer computer system by Web servers and/or the network.

[0063]FIG. 6 is a high-level block diagram of a typical network servicecenter computer system. The network service center computer system 340has one or more CPUs 610, a network connection 620, and a computerreadable media drive 630. The network service center computer systemfurther includes transient and/or persistent storage 640 containingnetwork service center software 641 for managing the record keepingassociated with purchase transactions, an HTTP server 642 for servingWeb pages, a customer database 643 for maintaining information on eachcustomer of the network, a merchant database 644 for maintaininginformation about each merchant, and a transaction database 645 formaintaining information about transactions entered into betweencustomers and merchants. While these tables, described in greater detailbelow, are each conceptually single tables, they may each be implementedusing more than one table, or a combination of data structures ofdifferent types.

[0064] To more clearly illustrate the operation of the network, itsoperation is described herein in conjunction with an example of its useby a customer. FIG. 7 is a screen shot diagram showing a Web pagedisplayed by a merchant. The Web page 700 includes information about themerchant, including information about products 711-714 that are offeredfor sale by the merchant. The information about each item includes alink that may be activated by the customer. For example, link 711 may beactivated by the customer to purchase the item “20 Questions on XML.”When the customer does so, the customer initiates the purchasingprocess.

[0065]FIG. 8 is a flow diagram showing the steps preferably performed bythe network as part of the purchasing process. These steps arepreferably performed by network service center software executing on thenetwork service center computer system and a transaction engineexecuting on the merchant computer system in conjunction with the Webbrowser executing on a customer computer system. Those skilled in theart will recognize, however, that these steps, as well as the othersteps shown in flow diagrams herein, may also be distributed to othercomputer programs executing on other computer systems in accordance withalternate network configurations.

[0066] In step 801, the network determines whether a valid sessioncookie is stored on the customer computer system in its cookie file 562.If so, this indicates that the customer computer system is being used bya registered customer who has already signed on to the network, and thenetwork continues in step 807. Otherwise, no registered user iscurrently signed onto the network from the customer computer system, andthe network continues in step 802. Step 801 is preferably performed byexamining time stamps in any network session cookies previously storedon the customer computer system by the network. These time stampsreflect the last time the customer signed on and the last time thecustomer made a purchase. The amount of time elapsed between these timesstored in the cookie and the present time indicates whether each sessioncookie is presently valid. For example, the network may determine that acookie indicating that the customer signed on less than six hours agoand completed his or her last purchase less than two hours ago is stillsigned onto the network, and that a network session cookie bearing thosetime stamps is valid.

[0067] In step 802, if the customer is already registered with thenetwork, the network permits the customer to sign on, and continues instep 803. If not, the network allows the user to register with thenetwork, and continues in step 804. In step 803, the networkauthenticates the customer based on information provided by the customeras part of a sign on process. FIG. 9 is a flow diagram showing the stepspreferably performed by the network in order to authenticate a customer.In step 901, the network collects from the customer the customer'smember identifier and password. FIG. 10 is a screenshot diagram showingthe sign on dialog box preferably displayed by the network to collectthe member identifier and password. The sign on dialog box 1000 includesa member identifier field 1001 and a password field 1002, into which thecustomer may type his or her member identifier and password,respectively. The user then selects the sign on button 1003 to submitthis information.

[0068] In step 902, the network also reads a customer cookie stored onthe customer computer system for the collected member identifier. Instep 903, the network extracts from the read customer cookie a uniqueidentifier for the user stored in the customer cookie by the network. Inone preferred embodiment, this unique identifier is the user's emailaddress, or other information specific to the domain of the user. Instep 904, if the combination of the collected user name and theextracted unique identifier correspond to a customer entry in thecustomer database, then the network continues in step 905, elseauthentication fails. In step 905, if the collected password is thecorrect password for that customer entry in the customer database, thenauthentication succeeds, else authentication fails.

[0069] Returning to FIG. 8, in step 804, the customer has elected toregister with the network by activating the register link 1004 in thesign on dialog box 1000. FIG. 11 is a flow diagram showing the stepspreferably performed by the network in order to register the customerwith the network. In step 1101, the network collects personalinformation about the customer, as well as payment information. Thepayment information preferably specifies a credit card account, but mayalternatively specify any method of payment selected by the operator ofthe network. The collection process is shown in FIG. 12. FIG. 12 is ascreenshot diagram showing a registration dialog 1200, into which theuser enters personal and payment information. The user preferably fillsin a first name field 1201, a last name field 1202, a postal code field1203, an email address field 1204, a credit card type field 1205, acredit card number field 1206, a credit card expiration date field 1207,a member ID field 1208, password fields 1209, and a shared secret field1210. It should be noted that the member ID 1208 may be any memberidentifier selected by the user, and does not need to be unique acrossthe network. After completing fields 1200 through 1210, the useractivates the register button 1211 to submit the information.

[0070] Returning to FIG. 11, in step 1102, the network verifies that theentered personal information is formatted correctly. For example, thenetwork verifies that the zip code in the customer's address has thecorrect number of digits. If personal information formattingverification fails, the network preferably requests that the user inputnew, correctly-formatted personal information and repeats step 1102. Instep 1103, the network verifies the entered payment information. Indoing so, the network preferably determines whether the credit cardnumber is valid, and whether the personal information collected matchesthe credit card number. As part of determining whether the credit cardis valid and active, the network may further attempt to obtainauthorization to charge a small amount to the credit card, to ensurethat the credit card is active. The network may further utilize thirdparty credit card verification or fraud detection services in performingstep 1103. If verification of payment information fails, the networkpreferably requests that the user input new, valid payment informationand repeats step 1103. In step 1104, the network creates an entry in thecustomer database for the customer containing the collected information.In step 1105, the network sends an email message to the customerannouncing the customer's successful registration with the network.After step 1105, the steps conclude.

[0071] Returning to FIG. 8, after registering the customer, in step 805,the network stores on the customer system a customer cookie identifyingthe customer by user name and unique identifier (preferably emailaddress). In step 806, the network stores on the customer computersystem a network session cookie documenting customer authentication. Thenetwork session cookie preferably includes the date and time ofauthentication. In step 807, the network determines whether the itemselected by the customer has already been purchased by the customer. Ifso, the network continues in step 811 to provide the purchased itemwithout charging the customer again. Otherwise, the network continues instep 808. In step 808, the network confirms the purchase with thecustomer. FIG. 13 is a screenshot diagram showing a confirmation dialogpreferably displayed by the network in step 808. The confirmation dialog1300 contains information 1301 about the purchase, including anidentification of the item, the purchase amount, and the duration orexpiration of the purchase. In order to complete the purchase, thecustomer activates the continue button 1302.

[0072] Returning to FIG. 8, in step 809, the network generates apurchase transaction, which it adds to its transaction database 645. Instep 810, the network updates the network session cookie stored on thecustomer computer system to reflect the present time as the time of thelast purchase. In step 811, the network provides to the user thepurchased item. After step 811, these steps conclude.

[0073]FIG. 14 is a screenshot diagram showing provision of a purchaseditem. The Web page 1400 is the purchased item selected by activatinglink 711 on the merchant Web page, “20 Questions on XML.” If the userleaves this Web page to continue browsing or turns off the customercomputer system, the customer can revisit this purchased item during theduration of the purchase by again selecting its link from the merchantWeb page. In response, the network immediately provides the purchaseditem without further interaction by the customer once the user isauthenticated by the network.

[0074] After the customer is authenticated, the customer may completeadditional purchases on the same or different merchant Web pages withoutreauthenticating. FIG. 15 is a screenshot diagram showing a Web page ofa second merchant. The Web page 1500 lists items 1501-1526 available forpurchase. The user may select link 1524 in order to select a marketreport item titled “Electrical Power Systems FY 98.” After selection ofthis link, a confirmation dialog is immediately displayed withoutrequiring the user to perform any authentication interactions.

[0075]FIG. 16 is a screenshot diagram showing the confirmation dialogdisplayed in response to the customer's activation of link 1524. Oncethe confirmation dialog box 1600 is displayed, the user need only selectthe continue button 1601 in order to complete the purchase of thisadditional item. After selecting this button, the “Electrical PowerSystems FY 98” report is displayed. FIG. 17 is a screenshot diagramshowing the provision of the additional purchased item. Web page 1700contains the purchased “Electrical Power Systems FY 98” item.

[0076] As a result of each purchase transaction, the transaction enginecreates a transaction record documenting the transaction, which isstored by the transaction engine at the merchant site. Periodically, apolling agent within the network service center software polls thetransaction engine at each merchant site to retrieve any transactionrecords generated on that merchant's site. The polling agent, uponretrieving these transactions, stores them each as a row in atransaction database maintained by the network. The transaction recordsare preferably aggregated by the network periodically into paymentrequests, which are requests to a payment processor to charge thecustomer's credit card or other form of payment. FIG. 18 is a tablediagram showing the transaction database maintained by the network.While the transaction table is shown for clarity as a single databasetable containing plain text, it will be appreciated by those skilled inthe art that it may be advantageously implemented in a more heavilyencoded and optimized form using conventional database techniques.

[0077] In the transaction table 1800, each row represents a transaction.Each row preferably contains data in at least six columns: a customercolumn 1801, a merchant column 1802, an item column 1803, an amountcolumn 1804, an expiration column 1805, and an outstanding column 1806.The customer column preferably contains the member ID of the customerthat entered into the transaction. For example, row 1812 contains themember identifier “Joe User.” The merchant column identifies themerchant with which the customer entered into the transaction. Forexample, row 1812 lists the merchant “Content Partner.” The item column1803 preferably identifies the purchased item. For example, in row 1812,the item is the “Twenty Questions on XML” item. The price column 1804preferably contains the amount of the purchased item. For example, inrow 1812, the price is “US$ 2.50”. The expiration column 1805 preferablycontains the time at which the purchase expires. For example, for row1812, the purchase expires at 2:25 p.m. on Nov. 3, 1998. Finally, theoutstanding column 1812 indicates whether the customer has yet paid forthe purchase. For example, in row 1812, the customer has not yet paidfor the purchase, so the transaction is still outstanding.

[0078]FIG. 19 is a flow diagram of the steps preferably performed by thenetwork in order to aggregate the transaction records in the transactiondatabase into payment requests sent to a payment processor. Thetransactions are preferably aggregated monthly on each customer'smonthly billing anniversary, but may be aggregated on any other desiredschedule. In steps 1901-1907, the network loops through each of aplurality of groups of customers. In a preferred embodiment, there is aseparate group of customers for each day of the month, and the loop ofsteps 1901-1907 is iterated once per day. In steps 1902-1905, thenetwork loops through each customer in the group. In step 1903, thenetwork determines the sum of the outstanding transactions of thecustomer. For example, for customer “Joe User” the network would add theamounts of rows 1812 and 1813, “US$ 2.50” and “US$ 1.00”, to determinethe sum of US$ 3.50. In step 1904, if the sum is greater than a billingthreshold, such as US$ 4. then the network continues in step 1905, elsethe network continues in step 1906. In step 1905, the network generatesa payment request for the determined sum against the credit card, orother form of payment, of the customer. In a preferred embodiment, thegenerated payment request has two parts: an authorization request, and asettlement request. The authorization request requests the authority tocharge the amount, while the settlement request requests actual paymentof the amount. In step 1906, if additional customers remain forprocessing, the network loops to step 1902 to process the next customerin the group. In step 1907, the network transmits the payment requestsgenerated in step 1905 to a payment processor in a batch. In step 1908,each day, the network loops back to step 1901 to process the next groupof customers.

[0079] Generally, for each batch of payment requests transmitted to thepayment processor, a payment report is received back from the paymentprocessor indicating whether each of the payment requests was paid. FIG.20 is a flow diagram showing the steps preferably performed by thenetwork in order to process a payment report. In step 2001, the networkreceives the payment report from the payment processor. In steps2002-2007, the network loops through each payment indication in thepayment report. Each payment indication generally corresponds to adifferent one of the payment requests included in the batch. In step2003, if the payment indication indicates that the correspondingauthorization was paid by the payment processor, then the networkcontinues in step 2005, else the network continues in step 2004. In step2004, the network, through inaction, permits the constituent transactionrecords to remain outstanding. The network may also take further steps(not shown) to immediately resubmit the payment requests, or to cancelthe account of the customer. After step 2004, the network continues instep 2007. In step 2005, the network credits the accounts of themerchants of the constituent transactions in accordance with thebusiness arrangement between the merchants and the operator of thenetwork. For example, the merchant “Stat USA” may have an arrangementwith the operator of the network in which the merchant receives ninetypercent of the amount of each purchase. Thus, for transaction record1813, the merchant “Stat USA” would be credited in the amount US$ 0.90.In step 2006, the network cancels the outstanding status of theconstituent transaction records so that they will not be incorporated inany future payment requests. In step 1907, if additional paymentindications remain in the payment report, the network loops back to step1902 to process the next payment indication. After step 2007, the stepsconclude.

[0080] With respect to the steps shown in FIGS. 19 and 20 and discussedabove, those skilled in the art will appreciate that, while these stepsare directed primarily to forms of payment such as credit cards andcheck cards, these steps may be straightforwardly adapted to obtainpayment from customers using different forms of payment.

[0081] In preferred embodiments, tasks relating to customerauthentication and purchasing are allocated within the network asfollows. Each item purchase link is preferably directed to a portion ofthe network called the transaction engine. A separate transaction engineis preferably located at each merchant site, so that, at any time thatcustomers are able to access the merchant Web pages to initiate apurchase transaction, a version of the transaction engine is availableto conduct the purchase transaction. The transaction engine reads andwrites network session cookies. In order to do so, the transactionengines for all of the merchants are preferably registered within asingle, central domain so that all of the transaction engines at all ofthe merchant sites may read and write the same cookies on the customercomputer system. When an item purchase link is activated, thetransaction engine checks for a valid network session cookie on thecustomer computer system, indicating that the customer has already beenauthenticated. If the transaction engine does not find a valid networksession cookie, the transaction engine redirects processing to acustomer information subsystem of the network. The customer informationsubsystem portion of the network performs authentication or registrationfor the customer, then instructs the transaction engine to confirm thetransaction, generate a transaction record, write or refresh the networksession cookie, and deliver the purchased item. To deliver the purchaseditem, in one embodiment, the transaction engine retrieves the data forthe item from the merchant, and delivers the data for the item to thecustomer.

[0082] In another embodiment of the invention, in order to avoid thetime and processing cost of relaying the data for the item through thetransaction engine, rather than itself retrieving the data for the item,the transaction engine sends a request to the merchant computer system,through the customer computer system, to transmit the data for the itemdirectly to the user. The request includes a “ticket”—an encrypted tokenattesting to the legitimacy of the request. At the merchant computersystem, an authorization subsystem decrypts and verifies the ticket,creates a merchant session cookie that is similar to the network sessioncookie and that attests to the purchase and the authentication of thecustomer, and transmits the data for the item to the customer computersystem.

[0083] Locating authorization subsystems at merchant computer systemsalso enables the network to manage customer authentication for merchantsin their own domains. When a customer attempts to access a restrictedportion of a merchant's Web site that is in a domain other than thecentral domain of the network, the authorization subsystem on themerchant computer system for that merchant checks to see whether a validmerchant cookie for that merchant is present on the customer computersystem. Such a merchant cookie, if it is present on the customercomputer system, attests to the current authentication of the user bythe merchant. If a valid merchant cookie for that merchant is present onthe customer computer system, the authorization subsystem allows accessto the restricted portion of the merchant's Web site. If not, theauthorization subsystem contacts the transaction engine. If thetransaction engine finds a valid network session cookie on the customermachine—that is, a cookie attesting to the authentication of thecustomer in the central domain—it instructs the authorization subsystemto write a merchant session cookie and permit access to the restrictedportion in the merchant's domain.

[0084] In a manner similar to the purchase process, if the transactionengine does not find a network session cookie on the customer machine,the transaction engine redirects processing to the customer informationsubsystem of the network. The customer information subsystem portion ofthe network performs authentication or registration for the customer,then instructs the transaction engine to create a network session cookieto the customer computer system. The transaction engine furtherinstructs the authorization subsystem to write a merchant session cookieand permit access to the restricted portion. In this way, the networkprovides a common method for signing onto the Web sites of all of themerchants, even those with restricted portions outside of the centralnetwork domain. Further, a customer may visit restricted areas ofseveral different merchants, and is only required to sign on once.

[0085] In addition to some or all of the foregoing features, the networkadditionally preferably provides customers with centralized, automatedservices for account management, product refunds, subscriptionmanagement, and multiple purchasing accounts linked to the same paymentaccount.

[0086] FIGS. 21-25 illustrate the automated product refund servicepreferably provided by the network. FIG. 21 is a screenshot diagramshowing a sample customer statement. The statement 2100 containsentries, such as entries 2110 and 2120, each containing informationabout an item purchased by the customer named “Joe User.” For example,entry 2120 in the statement contains information about the “ElectricalPower Systems FX 98” report purchased from “Stat USA.” The statementfurther includes the current balance 2130 for this account.

[0087] Each entry includes a link for displaying additional detail aboutthe purchased item. For example, entry 2120 includes link 2121, whichthe user may activate to display additional information about the StatUSA report. FIG. 22 is a screenshot diagram showing a sample iteminformation page. The item information page 2200 includes information2210 about the item. This information includes a link 2211 that can beactivated to access the purchased item. The item information page alsoincludes a button 2220 that can be activated to request a refund for theitem. A customer may wish to request a refund, for example, if the itemwas ordered by mistake, if the item does not conform to the customer'sexpectations or if the item could not be properly downloaded.

[0088]FIG. 23 is a screenshot diagram showing a sample refund request.The refund request 2300 is displayed in response to the customer'sactivation of button 2340. The refund request contains information 2310about the item for which a refund is sought, a listbox 2320 forspecifying a reason for the refund request, and a field 2330 forentering a further explanation of the circumstances surrounding therequest for refund. The refund request further contains a button 2340that can be activated to submit the refund request. FIG. 24 is ascreenshot diagram showing a sample confirmation screen confirming arefund request. The confirmation screen 2400 is preferably displayed inresponse to the activation of button 2340.

[0089] After the refund request is submitted, the customer's statementis preferably updated to reflect the submission of the refund request.FIG. 25 is a screenshot diagram showing a sample statement reflectingthe submission of a refund request. The updated statement 2500 includesa line 2521 indicating that a refund has been requested for item 2520.Line 2521 further indicates that the price of item 2520, $1.00, is beingdeducted from the account balance while the refund request is beingconsidered. As a result, the account balance 2530 is reduced to includeonly the price of item 2510.

[0090] In processing refund requests, the network preferably employs amaximum automatic refund threshold. If a refund request is directed toan item having a price that is less than the maximum automatic refundthreshold, the network preferably automatically grants the refundrequest. On the other hand, the network applies a more rigorousevaluation process to refund requests that are directed to items havingprices greater than the maximum automatic refund threshold. The networkpreferably forwards such refund requests to a human customer servicerepresentative. This use of a maximum automatic refund thresholdreflects a recognition that evaluation by a human customer servicerepresentative may incur a significant cost that, in many cases, exceedsthe cost of granting the refund. In a preferred embodiment, the maximumautomatic refund threshold is set at $10.00. As a result, a customer mayconveniently complete the submission of a refund request withoutinteracting directly with a human customer service representative.Further, in most cases, the network relieves its operator of any need toexpend customer service representative time to process refund requests.

[0091] FIGS. 26-27 illustrate the automated, centralized subscriptionmanagement service preferably provided by the network. FIG. 26 is ascreenshot diagram showing a sample subscription management page. Thesubscription management page 2600 contains entries, such as entries 2610and 2620, each containing information about a subscription purchased bythe customer named “Joe User.” For example, entry 2610 in thesubscription management page contains information about a subscriptionto the “Wall Street Journal.” Each entry also includes an indication ofthe expiration date of the subscription, as well as an indication ofwhether the subscription will automatically renew when it expires.

[0092] Each entry includes a link for displaying information about ormodifying the subscription. For example, entry 2610 includes link 2611,which the user may activate to display additional information about theWall Street Journal subscription. FIG. 27 is a screenshot diagramshowing a sample subscription information page. The subscriptioninformation page 2700 includes information 2710 about the subscription.This information includes a link 2711 that can be activated to accessthe subscription. The item information page also includes buttons2721-2723 for modifying the subscription. The user may activate button2721 to immediately renew the subscription for another term. When button2721 is activated, the network updates the subscription management andsubscription information pages to extend the expiration date of thesubscription by the length of a term, and notifies the transactionengine at the merchant site to update the status of the subscription.The user may activate button 2722 to specify that the subscriptionshould automatically renew for another term when the present termexpires. When button 2722 is activated the network updates thesubscription management and subscription information pages to indicatethat the subscription will automatically renew, and notifies thetransaction engine at the merchant site to update the status of thesubscription. The user may activate button 2723 to cancel thesubscription. When button 2722 is activated, the network preferablycredits the customer's account for a pro-rated portion of thesubscription price. The network further updates the subscriptionmanagement page to remove the entry for this subscription, and notifiesthe transaction engine at the merchant site to update the status of thesubscription.

[0093] As a result a customer may conveniently perform subscriptionmanagement operations without interacting directly with a human customerservice representative. Further, the network relieves its operator ofany need to expend customer service representative time to processsubscription management operations.

[0094] In order to facilitate purchasing by multiple customers who payfor purchases together, the network preferably provides a feature inwhich it associates multiple purchasing accounts with a single paymentaccount. This feature enables a company to pay for and track thepurchases of its employees, a parent to pay for and track the purchasesof his or her children, or an individual to separate his or her businesspurchases from his or her personal purchases. In accordance with thisfeature, a first customer may register as described above, in order toobtain both a purchasing account for purchasing items, and a paymentaccount for paying for those purchases. At a later time, the firstcustomer may create additional purchasing accounts that are “associated”with the payment account, either for others, or for himself or herself.Any purchases made with an additional purchasing account are consumedusing the additional purchasing account, and are billed to theassociated payment account, using the payment information associatedwith this payment account.

[0095] FIGS. 28-30 illustrate the multiple purchasing accounts featurepreferably provided by the network. In a preferred embodiment, anadditional purchasing account can be added to an existing paymentaccount by a customer signed on to an existing purchasing accountassociated with the payment account. FIG. 28 is a screenshot diagramshowing a sample registration page for registering an additionalpurchasing account for an existing payment account. In the example, theregistration page shown is used by the customer named “Joe User” to addan additional purchasing account for “Jean User” to his existing paymentaccount. The registration page contains fields 2810 into which thecustomer enters information about the customer that will use theadditional purchasing account, including the email address of thiscustomer, and the user name and password to be used with the additionalpurchasing account. After entering this information, the customeractivates button 2820 to register the additional purchasing account.

[0096] After the additional purchasing account has been registered, itmay be used by Jean User to purchase items. FIG. 29 is a screenshotdiagram showing a sample customer statement showing purchases made withthe additional purchasing account. The customer statement 2900 containsentries 2910 and 2920 for items purchased by Jean User using herpurchasing account. The customer statement further contains a total 2930of the items that Jean User has purchased. It should be noted that, inthe preferred embodiment shown, items purchased using other purchasingaccounts associated with the same payment account (e.g., those purchasedby Joe User using his purchase account, shown in FIG. 21) are not shownon the customer statement or included in the total.

[0097] On the other hand, customers signed on to the payment account (orto the first purchasing account, which is preferably more tightlycoupled to the payment account than are additional purchasing accounts)may display the purchases made using other customer accounts associatedwith the same payment account. FIG. 30 is a screenshot diagram showing asample customer statement showing purchases made with multiplepurchasing accounts that are each associated with the same paymentaccount. The customer statement 3000 includes both entries 3010 and 3020describing purchases made by Joe User using his purchasing account, andentries 3030 and 3040 describing purchases made by Jean User using herpurchasing account. Additionally, the customer statement shows a total3050 that reflects the purchases made by both Joe User and Jean User. Itcan be seen that this statement permits a user of a payment account toreview the purchases made using all of the purchasing accountsassociated with the payment account, and to determine the amount thatwill requested in the next payment request generated by the network forthe payment account.

[0098] While this invention has been shown and described with referenceto preferred embodiments, it will be understood by those skilled in theart that various changes or modifications in form and detail may be madewithout departing from the scope of the invention. For example, insteadof operating in conjunction with multiple merchants, the network mayoperate in conjunction with a single merchant. Further, thefunctionalities provided by the network may be allocated differentlyacross the described computer systems, or may be provided by a differentcombination of computer systems than described. Further, these computersystems may be connected by a combination of different networks, insteadof by a single network such as the Internet. The network may further bereconfigured to more optimally perform in particular businessenvironments. Additionally, the network may be used to sell goods andservices other than digital goods, including physical goods. Also, thenetwork may preferably accept payment information and generate paymentrequests for any form of payment, or any combination of different formsof payment.

We claim:
 1. A method in a computer network for managing purchasetransactions for the Web sites of a plurality of merchants using atransaction network, comprising the steps of: for each of the pluralityof merchant Web sites, under the control of the merchant Web site:displaying items available for purchase, each item having a price;receiving user input from users using Web clients selecting items forpurchase; and for each item selection, forwarding a purchase request tothe transaction network indicating the price of the selected item; underthe control of the transaction network: receiving transaction networkpurchase requests forwarded from the plurality of merchant Web sites;for each received purchase request: discerning the identity of the user;and generating a pending transaction record indicating the identity ofthe user, the price of the selected item, and the identity of theforwarding Web site; periodically determining, for each user whoseidentity is indicated by a pending transaction record, the sum of theprices of the pending transaction records indicating the identity of theuser; where the determined sum for a user exceeds a billing thresholdsubmitting to a payment processor a request for settlement for thedetermined sum against an account of the user; receiving settlementindications from the payment processor each indicating payment of anidentified submitted a request for settlement; for each receivedsettlement indication, for each transaction record whose price isincluded in the sum of the billing transaction identified by thereceived settlement indication: crediting an account of the merchantidentified by the transaction record; and removing the pending status ofthe transaction record.
 2. A method in one or more computer systems forprocuring payment for purchase transactions each originating with aparticular user and vendor, comprising the steps of: receiving purchaserequests each originating at one of a plurality of vendor Web sites,each purchase request indicating a purchase price; for each receivedpurchase request: discerning the identity of a user with which thepurchase request originated; and storing a pending transaction recordindicating the identity of the user, the purchase price, and theidentity of the vendor at whose Web site the purchase requestoriginated; periodically determining, for each user whose identity isindicated by a pending transaction record, the sum of the prices of thepending transaction records indicating the identity of the user; wherethe determined sum for a user exceeds a billing threshold, submitting toa payment processor a billing transaction for the determined sum againstan account of the user; receiving settlement indications from thepayment processor each indicating payment of an identified submittedbilling transaction; for each received settlement indication, for eachtransaction record whose price is included in the sum of the billingtransaction identified by the received settlement indication: creditingan account of the vendor identified by the transaction record; andremoving the pending status of the transaction record.
 3. One or morecomputer memories collectively containing a data structure forpurchasing items from different vendors, the data structure comprising:a first Web page, under the control of a first vendor, containinginformation describing a first item and a first link to a purchasingsystem not under the control of the first vendor, the first linkactivatable by users to purchase the first item: a second Web page,under the control of a second vendor distinct from the first vendor,containing information describing a second item and a second link to thepurchasing system, the purchasing system also not under the control ofthe second vendor, the second link activatable by users to purchase thesecond item; instructions stored in a purchasing system, theinstructions responding to the activation of the first link by:identifying the user activating the first link; establishing an accountfor the identified user if one has not yet been established; causing thepurchase of the first item to be posted to the account of the identifieduser; and providing the first item to the identified user, theinstructions responding to the activation of the second link by:identifying the user activating the second link; establishing an accountfor the identified user if one has not yet been established; causing thepurchase of the second item to be posted to the account of theidentified user; and providing the second item to the identified user.4. The computer memories of claim 3 wherein the instructions stored onthe purchasing system are provided in an active server object.
 5. Amethod in a computer system for generating payment requestsincorporating multiple purchase transactions, comprising the steps of:receiving purchase transaction indications, each purchase transactionindication indicating an amount and identifying one of a plurality ofcustomers; for each customer: periodically determining the sum of theamounts of the received purchase transaction indications identifying thecustomer that have not been incorporated in a payment request; and whenthe determined sum exceeds a billing threshold, generating a new paymentrequest for the customer in the amount of the sum that incorporates thereceived purchase transaction indications identifying the customer thathave not been incorporated in a payment request.
 6. The method of claim5 wherein the receiving step receives purchase transaction indicationsfrom a number of different vendors often whom the customers have madepurchases.
 7. The method of claim 6, further comprising the steps of:for each vendor, collecting transaction indications indicatingtransactions entered into with the vendor; and retrieving the collectedtransaction indications from each vendor.
 8. The method of claim 5wherein the generating step generates settlement requests, and whereinthe method further comprises the step of transmitting generatedsettlement requests to a payment processor for settlement.
 9. Acomputer-readable medium whose contents cause a computer system togenerate billing transactions incorporating multiple purchasetransactions by performing the steps of: receiving purchase transactionindications, each purchase transaction indication indicating an amountand identifying one of a plurality of customers; and for each customer:periodically determining the sum of the amounts of the received purchasetransaction indications identifying the customer that have not beenincorporated in a billing transaction; and when the determined sumexceeds a billing threshold, generating a new billing transaction forthe customer in the amount of the sum that incorporates the receivedpurchase transaction indications identifying the customer that have notbeen incorporated in a billing transaction.
 10. The computer-readablemedium of claim 9 wherein the receiving step receives purchasetransaction indications from a number of different content providerswith whom the customers have entered into purchase transactions.
 11. Acomputer system for generating billing transactions incorporatingmultiple purchase transactions, comprising: a receiver that receivespurchase transaction indications, each purchase transaction indicationindicating an amount and identifying one of a plurality of customers; anadder that, for each customer, periodically determines the sum of theamounts of the received purchase transaction indications received by thereceiver that identify the customer that have not been incorporated in abilling transaction; and a billing transaction generator that, when thesum determined by the adder exceeds a billing threshold, generates a newbilling transaction for the customer in the amount of the sum thatincorporates the received purchase transaction indications identifyingthe customer that have not been incorporated in a billing transaction.12. A method in a computer system for aggregating charge transactionsentered into by a customer, the method comprising the steps of: overtime, receiving a stream of charge transactions entered into by thecustomer, each charge transaction having an amount; identifying a timeat which the sum of the amounts of the received charge transactionsexceeds a threshold amount; and submitting to a payment processor apayment request for the sum of the received charge transactions.
 13. Themethod of claim 12 wherein one of the received charge transactions wasentered into in conjunction with a third-party vendor, furthercomprising the steps of: receiving from the payment processor, inresponse to the submitting step, a settlement indication indicatingpayment of the submitted payment request; and in response to the step ofreceiving a settlement indication, crediting to the vendor a portion ofthe sum.
 14. A computer-readable medium whose contents cause a computersystem to process charge transactions entered into by a customer byperforming the steps of: receiving a stream of charge transactionsentered into by the customer, each charge transaction having an amount;identifying a time at which the sum of the amounts of the receivedcharge transactions exceeds a threshold amount; and submitting to apayment processor a settlement request for the sum of the receivedcharge transactions.
 15. The computer-readable medium of claim 14wherein one of the received charge transactions was entered into inconjunction with a third-party vendor, and wherein the contents of thecomputer-readable medium further cause the computer system to performthe steps of: receiving from the payment processor, in response to thesubmitting step, a payment indication indicating payment of thesubmitted settlement request; and in response to the receiving step,crediting to the vendor a portion of the sum.
 16. A computer memorydevice storing a charge aggregation data structure for storinginformation about charge transactions directed to a particular form ofpayment, the form of payment having a minimum threshold for chargesagainst the form of payment, the data structure comprising a pluralityof records each representing a distinct charge transaction, each recordindicating an amount for the transaction it represents, at least some ofthe records indicating amounts below the minimum threshold for the formof payment, such that the data structure may be accessed to combine aplurality of the charge transactions into a single aggregate transactionhaving an amount corresponding to the combined amounts indicated by therecords that is in excess of the minimum threshold, such that theaggregate transaction may be charged against the form of payment. 17.The computer memory device of claim 16 wherein the form of payment is acredit card.
 18. The computer memory device of claim 16 wherein the formof payment is a debit card.
 19. The computer memory device of claim 16wherein the form of payment is an automated clearing house payment. 20.The computer memory device of claim 16 wherein the form of payment is anelectronic funds transfer transaction.
 21. The computer memory device ofclaim 16 wherein the form of the payment is a purchase order.
 22. Thecomputer memory device of claim 16 wherein each record of the datastructures identifies one of a plurality of customers as having enteredinto the transaction represented by the record, such that the datastructure may be accessed to combine a plurality of the chargetransactions into a plurality single aggregate transactions eachcorresponding to a single customer.
 23. A memory device storing anaggregate charge data structure, the aggregate charge data structurebeing suitable for submission to a payment processor for payment, thedata structure comprising: a consumer identifier identifying a consumerthat has charged a multiplicity of purchase transactions, each purchasetransaction having an amount; and an aggregate charged amountconstituting the sum of the amounts of a constituent plurality of themultiplicity of purchase transactions charged by the consumer, at leastone of the amounts of the constituent purchase transactions fallingbelow a minimum threshold for submitting charges to a payment processorfor payment, such that the data structure may be submitted to a paymentprocessor for payment in place of the constituent purchase transactions.24. The memory device of claim 23 wherein the data structure furthercomprises both a consumer identifier and aggregate charged amount foreach of a plurality of additional consumers.
 25. A method in a computersystem for identifying a user using a user computer system among a groupof users, the method using a potentially non-unique member identifier,the method comprising the steps of: (a) registering the user by: (1)obtaining for the user a member identifier that is potentially notunique; (2) after obtaining the solicited member identifier in step(a)(1), storing a unique identifier for the user on the user computersystem in conjunction with the obtained member identifier; and (b)identifying the user by: (1) soliciting from the user the memberidentifier of the user; (2) receiving from the user, in response to step(b)(1), the member identifier of the user; (3) reading from the usercomputer system the unique identifier stored in conjunction with themember identifier received in step (b)(2); (4) identifying the userusing the unique identifier read in step (b)(3).
 26. The method of claim25 wherein a plurality of users having the same user computer system areregistered by repeating steps (a)(1)-(a)(2) for each of the plurality ofusers.
 27. The method of claim 25 wherein obtaining step (a)(1)comprises the steps of: soliciting from the user a member identifier ofthe user; and receiving from the user a member identifier of the user.28. The method of claim 25 wherein the method is practiced on behalf ofa first online service, and wherein obtaining step (a)(1) comprises thestep of obtaining for the user a member identifier used by the user toidentify himself or herself to second online service distinct from thefirst online service.
 29. The method of claim 28 wherein the step ofobtaining for the user a member identifier used by the user to identifyhimself or herself to second online service obtains the memberidentifier from an operator of the second online service.
 30. A methodin one or more computer systems for purchasing products offered for saleby multiple vendors, comprising the steps of: receiving a single,contiguous set of user interface interactions for establishing theidentity of the user; establishing the identity of the user based on thesingle, contiguous set of user interface interactions received in thereceiving step; purchasing an item offered for sale by a first vendorbased on the user identity established in the establishing step; andpurchasing an item offered for sale by a second vendor distinct from thefirst vendor based on the user identity established in the establishingstep.
 31. The method of claim 30, further comprising the steps of: inconjunction with the step of purchasing an item offered for sale by afirst vendor, displaying a visual indication of the first vendor; and inconjunction with the steps of purchasing an item offered for sale by asecond vendor, displaying a visual indication of the second vendor. 32.The method of claim 30 wherein the receiving and establishing steps areperformed as part of the step of purchasing an item offered for sale bythe first vendor.
 33. The method of claim 30 wherein the second vendorhas a computer system and wherein the establishing step includes thestep of storing a central state signifying the establishment of theidentity of the user, and wherein the step of purchasing an item offeredfor sale by the second vendor include the steps of: checking the storedstate; in response to checking the stored state, sending an encodedticket to the second computer system; under the control of the secondcomputer system: decoding the encoded ticket; validating the decodedticket; and performing the step of purchasing an item offered for saleby the second vendor in response to the validating step.
 34. The methodof claim 30 wherein the establishing step includes the step of storing acentral state signifying the establishment of the identity of the user,and wherein the step of purchasing an item offered for sale by a secondvendor include the steps of: checking the stored central state; andperforming the step of purchasing an item offered for sale by a secondvendor in response to the checking step.
 35. A method in one or morecomputer systems for accessing multiple access-restricted Web sites,comprising the steps of: receiving a single, contiguous set of userinterface interactions for establishing the identity of the user;establishing the identity of the user based on the single, contiguousset of user interface interactions received in the receiving step;granting access to a first access-restricted Web site based on the useridentity established in the establishing step; and granting access to asecond access-restricted Web site distinct from the secondaccess-restricted Web site based on the user identity established in theestablishing step.
 36. The method of claim 35, wherein the secondaccess-restricted Web site is served by a second computer system, andwherein the establishing step includes the step of storing a statesignifying the establishment of the identity of the user, and whereinthe step of granting access to the second access-restricted Web siteinclude the steps of: checking the stored state; in response to checkingthe stored state, sending an encoded ticket to the second computersystem; under the control of the second computer system: decoding theencoded ticket; validating the decoded ticket; and performing the stepof granting access to the second access-restricted Web site in responseto the validating step.
 37. The method of claim 35 wherein theestablishing step includes the step of storing a central statesignifying the establishment of the identity of the user, and whereinthe step of granting access to the second access-restricted Web siteinclude the steps of: checking the stored central state; and performingthe step of granting access to the second access-restricted Web site inresponse to the checking step.
 38. A transaction network for vendingdigital content from a plurality of merchants comprising: for eachmerchant, a transaction engine for conducting transactions withcustomers to purchase digital content and deliver purchased digitalcontent; and a network service center for collecting indicia oftransactions entered into with each merchant and submitting paymentrequests for the collected transactions to a payment processor.
 39. Thetransaction network of claim 38 wherein the network service centeraggregates the transactions conducted with each customer, and whereinthe payment requests are submitted for the aggregated transactions. 40.The transaction network of 39 wherein the network service center furtherreceives from the payment processor indications of the payment of thesubmitted payment requests, and, for each received indication, creditsthe merchants with which the transactions aggregated into the requestwhere conducted.
 41. A method in one or more computer systems forproviding to a customer automatic refund support for a purchasetransaction, the method comprising: generating for the customer adisplay soliciting information supporting a request for refund of thepurchase transaction; receiving from the customer, in response to thegenerated display, information supporting a request for refund; andautomatically generating a request for refund incorporating the receivedinformation, such that the customer requests a refund of the purchasetransaction without additional interaction.
 42. The method of claim 41,further comprising the steps of: generating for the customer a displaycontaining indicators of each of a plurality of transactions enteredinto by the customer, at least two of the plurality of transaction beingentered into with different merchants; and receiving from the customer aselection of the transaction indication of a selected transaction, andwherein the step of generating a display soliciting information tosupport a request for refund of a service transaction generates adisplay soliciting information to support a request for refund of theselected transaction.
 43. The method of claim 41 wherein the transactionhas an amount, the method further comprising the steps of: determiningwhether the amount of the transaction is less than a maximum threshold;and if the amount of the transaction is less than the maximum threshold,automatically granting the requests for refund.
 44. The method of claim43, further comprising the step of, if the amount of the transaction isnot less than the maximum threshold, determining whether to grant therequest for refund based upon the information supporting the request forrefund.
 45. A method in one or more computer systems for enabling asubscriber to manage content subscriptions from a plurality of contentsources, the method comprising: displaying for the subscriber anindication of each of a plurality of content subscriptions entered intoby the subscriber, at least two of the content subscriptions being withdifferent content sources; receiving from the subscriber a selection ofthe indication of a selected content subscription; and on behalf of thesubscriber, performing a subscription management operation with respectto the selected content subscription.
 46. The method of claim 45 whereinthe performing step cancels the selected content subscription.
 47. Themethod of claim 45 wherein the performing step renews the selectedcontent subscription.
 48. A method in one or more computer systems forproviding a plurality of purchasing accounts for purchasing digitalcontent, all of the purchasing accounts of the plurality beingassociated with a single payment account, the method comprising: storingpayment information for the payment account that is usable to procurepayment for digital content purchases made using any of the plurality ofpurchasing accounts; storing for each of the purchasing accounts adifferent account identifier; in response to each purchase requestspecifying content received in connection with the account identifier ofone of the purchasing accounts: completing a purchase of the specifiedcontent, and providing the specified content; and utilizing the paymentinformation stored for the payment account to procure payment fordigital content purchases completed using any of the plurality ofpurchasing accounts.
 49. The method of claim 48, further comprising thesteps of: storing an account identifier for the payment account; and inresponse to a request received in connection with the account identifierfor the payment account, displaying information describing the purchasescompleted using any of the plurality of purchasing accounts.
 50. Themethod of claim 48, further comprising the step of, in response to arequest received in connection with the account identifier for aselected one of the purchasing accounts, displaying informationdescribing the purchases made completed using only the selectedpurchasing account.